FIG. 1 is a flowchart of the existing CCBS service, as shown in FIG. 1, the flow of the existing CCBS service comprises:
Step 1: a calling subscriber A calls a called subscriber B, and the called subscriber B rejects a call invite from the calling subscriber A for subscriber busy;
Step 2: an Originating Application Server (O_AS) sends a subscribe message (SUBSCRIBE) to the T_AS to subscribe the idle state of the called subscriber;
Step 3: after receiving the SUBSCRIBE from the O_AS, the Terminating Application Server (T_AS) returns a 202OK message to the O_AS to acknowledge receiving the SUBSCRIBE;
after step 3, the T_AS begins to perform a busy state supervision on the called subscriber B (a busy state supervision begins), and when the current state of the called subscriber B is detected to become available (user B becomes available), Step 4 is executed;
Step 4: when the called subscriber is idle, the T_AS transverses the list of the O_AS subscribing the idle state of the subscriber and sends a notification message (NOTIFY) to the first O_AS subscribing the idle state currently;
Step 5: after receiving the NOTIFY, the O_AS returns a 200OK acknowledgment message to the T_AS; and
Step 6˜Step 10: the O_AS notifies the calling subscriber A of initiating a recall invite (INVITE) in an REFER mode, and adds call completion indicator (CC call indicator) information into the call invite of the calling subscriber A; or the O_AS sends a 3rd Party Call Control (3PCC) flow, sends a call invite to the called subscriber B and adds call completion indicator information in the call invite.
After receiving the call invite, the T_AS judges whether the call invite includes the call completion indicator information, if the call invite includes the call completion indicator information, the T_AS forwards the call invite to the called subscriber B; and, if the call invite does not include the call completion indicator information, the T_AS rejects the current call invite by a 486 (Busy Here) failure response.
If the T_AS allows this call, the subsequent processing flow will be continued to complete this call.
FIG. 2 is a flowchart illustrating performing a malicious call based on FIG. 1, as shown in FIG. 2, performing a malicious call by a malicious call subscriber is specifically as follows:
the processing way in step 1 to step 5 here are completely as same as that in step 1 to step 5 in FIG. 1, thereby needing no further description for details;
Step 6: a malicious subscriber or an other application server sends a call invite to the T_AS, wherein the malicious subscriber inserts call completion indicator information in the call invite initiated by the malicious subscriber per se; the T_AS will process the call of the malicious subscriber according to the circumstance of the calling subscriber A in step 1 to step 5, i.e., taking the call invite of the current malicious subscriber as a subscriber of the CCBS service;
Step 7: the T_AS forwards the call invite of the malicious subscriber to the called subscriber B to perform a call access;
in this way, the malicious subscriber is accessed to the called subscriber B prior to a normal subscriber A; and
the processing flow in step 8 to step 12 corresponds to that in FIG. 1, thereby needing no further description for details.
It can be seen from FIG. 2 that, if a malicious subscriber adds call completion indicator information into a call invite by itself, the originating network does not filter the message, such that the call invite of the malicious subscriber including call completion indicator information will be sent to the T_AS to set up a call. In this way, a calling subscriber firstly initiating a subscription fails to complete the call at first, but a calling subscriber initiating subscription later completes the call. So, the malicious subscriber equivalently jumps the queue. Obviously, this is not favourable for calling justification and may even affect the normal calling of normal subscribers.